1. Field of the Invention
This invention relates to the field of computer program control applications such as a debugging application. Specifically, this invention includes a method, apparatus, and computer program product for enabling a controlling programmed-process to control a target programmed-process executing in a computer having an operating system that provides programmed-processes with multiple, separately schedulable, threads of execution.
2. Background
Controlling programmed-processes are applications that directly control a target programmed-process without programmed cooperation by the target programmed-process. A controlling programmed-process is often used as a program debugging application. A debugging application provides a programmer with tools for examining, modifying, monitoring, and controlling the execution of the target programmed-process being debugged. The debugging application must not inadvertently change the state of the target programmed-process. The prior art controlling programmed-process controls the target programmed-process by co-opting a thread of execution in the target programmed-process. The prior art in multithreaded operation is discussed in Multithreaded Implementations and Comparisons, by Sun Microsystems, Inc., copyright 1996. A particular implementation of the prior art is discussed in SunOS Multi-thread Architecture, by Powell, Kleiman, Barton, Shah, Stein and Weeks, USENIX, Winter 1991, page 65.
A prior art controlling programmed-process first stops all lightweight programmed-processes (LWPs) owned by the target programmed-process. Once all the LWPs are stopped, the controlling programmed-process co-opts one of the target programmed-process's LWPs to perform debugging operations within the target programmed-process's address space. The controlling programmed-process co-opts the target programmed-process's LWP by specifying where in the target programmed-process the LWP is to execute once the LWP is resumed. Thus, the controlling programmed-process can insert computer instructions within the target programmed-process and cause these inserted computer instructions to be executed by the target programmed-process on behalf of the controlling programmed-process. This operation is subsequently described with respect to FIGS. 1a and 1b. Briefly, the LWP is co-opted by stopping the LWP either before, during, or after execution of an operating system service requested by the target programmed-process. The co-opted LWP is restarted from where it was stopped after the co-opted LWP is used by the controlling programmed-process. The LWP is restarted by adjusting the LWP to reissue the computer instruction that invoked the stopped operating system service (if the LWP was stopped prior to the system providing the requested service) or to execute the computer instruction after the instruction that invoked the stopped operating system service (if the LWP was stopped after the system provided the requested service).
A problem exists when the LWP is stopped during execution of the operating system service when only a portion of the operating system service has been completed (such as during a non-atomic system service). In this circumstance, if the instruction that invoked the operation is not reissued, the LWP will continue without the requested system service operation completing. On the other hand, if the instruction is reissued, portions of the requested system service operation will be duplicated. Both of these conditions cause unexpected side-effects in the target programmed-process and are a result of the operation of a controlling programmed-process operation on the target programmed-process. Thus the controlling programmed-process can cause incorrect operation of the co-opted LWP when the co-opted LWP is restarted.